AWS Security Hub を中央設定する場合の管理アカウントについて考える

「管理アカウントのSecurity Hubの有効化方針が悩ましい。」

使用しないリージョンはSCPで拒否(Control Towerのリージョン拒否コントロールや独自SCP)することでセキュリティを担保する運用時に、管理アカウントの扱いが悩ましいことがあります。

管理アカウントはSCPによる制限ができないからです。

関連ブログとして以下があります。

Security Hub をリージョン集約・Organizations 統合する場合の管理アカウントについて考える | DevelopersIO

今回は以下を前提に、管理アカウントのSecurity Hubの扱いについて考えてみます。

• AWS Security Hubは中央設定を利用して設定を一元管理する
• 管理アカウントのGuardDutyは全リージョン有効化して、通知設定まで行う
• メンバーアカウントは利用リージョンのみGuardDutyを有効化する(利用しないリージョンは、SCPでリージョン自体の操作を制限する)

結論

• ポイントはSecurity Hub中央設定のクロスリージョン集約のリンクされたリージョン
  • リンクされたリージョンがSecurity Hub中央設定の設定対象となる
• Security Hubで通知を集約したい・使わないリージョンでセキュリティ標準が有効でも問題ない -> 全リージョンをリンク
• 使わないリージョンでセキュリティ標準を有効化したくない・管理アカウントだけ通知方法が異なっても問題ない -> 利用リージョンのみをリンク

理想

理想は以下のように、管理アカウントは全リージョン・メンバーアカウントは利用リージョンのみをSecurity Hubで集約して、Security Hub委任管理アカウントで確認する構成です。

しかし、現時点ではこの構成は実現不可です。

Security Hubの中央設定の仕様で、委任管理アカウントのクロスリージョン集約設定がOrganizations内のアカウントに反映されるためです。

そのため、委任管理アカウントで利用リージョンのみをリンクすると、管理アカウントの全リージョンを集約できません。

逆に、全リージョンをリンクすると、メンバーアカウントの使わないリージョンでセキュリティ標準が有効になります。

詳しくは以下の記事をご確認ください。

AWS Security Hub中央設定 セルフマネージドアカウントでもクロスリージョン集約は委任先アカウントの設定が反映される | DevelopersIO

クロスリージョン集約のリンクするリージョン

案1 全リージョン

Security Hub委任アカウントのクロスリージョン集約で全リージョンをリンクするパターンです。

Security Hub中央設定

Security Hub セキュリティ基準

Security Hub委任アカウントで管理アカウントのSecurity Hubも集約して確認することが可能です。

委任アカウントのSecurity Hubに対して、通知設定を行えば良いので通知もシンプルです。

一方、メンバーアカウントで利用しないリージョンもSecurity Hubのセキュリティ基準が有効になります。

案2 利用リージョンのみ

Security Hub委任アカウントのクロスリージョン集約で利用リージョンのみをリンクするパターンです。

Security Hub中央設定

Security Hub セキュリティ基準

※リソースは作成しない想定のため無効。個別で設定すれば有効化することは可能。

メンバーアカウントで利用しないリージョンのSecurity Hubセキュリティ標準が有効にならないパターンです。

管理アカウントのGuarDutyの通知は直接EventBridgeを使用しています。

Security Hubを利用する場合、集約が利用リージョンのみになるためです。

管理アカウントだけ利用リージョンはSecurity Hub、その他リージョンはEventBridgeだと通知方法が2種類になり運用が煩雑になりそうです。(各リージョンのSecurity Hubを経由することも可能ですが、GuardDutyだけであれば、あまりメリットが無い想定です)

そのため、管理アカウントはEventBridgeに統一しました。

GuardDutyの通知をEventBridge集約する方法については、以下のブログをご確認ください。

GuardDuty 全リージョン分の検出結果を EventBridge で集約してからメール通知する CloudFormation テンプレートの紹介 | DevelopersIO

案1と案2の比較

通知設定

全リージョンの場合は、委任アカウントのSecurity Hubで管理アカウントも含めて集約できます。

通知は委任アカウントの集約リージョンのSecurity Hubに設定するだけで良いです。

一方、利用リージョンのみの場合は、管理アカウントは別の仕組みが必要になります。

• 管理アカウント
  • (管理アカウント)リージョンごとのEventBridge Rule　-> (委任アカウント)EventBridge Rule
• メンバーアカウント
  • (委任アカウント)Security Hub -> (委任アカウント)EventBridge Rule

通知方法が1つで済むため、全リージョン集約の方がシンプルになります。

Security Hubセキュリティ標準

全リージョンでは、利用しないリージョンでもSecurity Hubのセキュリティ標準が有効になります。

Security Hubセキュリティ標準の動作には、当該リージョンのAWS Configの有効化が必要です。

AWS Configが無効な場合、Security Hubで「[Config.1]AWS Config should be enabled」のFindingが検出され続け通知のノイズになります。

通常のコントロールはAWS Configルールを使って、評価を行います。

しかし、Config.1は特殊なルールでAWS Configルールを使わずに評価が行われるため、AWS Configが無効な状態でもコントロールが有効になります。

回避するには、当該コントロールの無効化やAWS Configの有効化が必要になります。

利用するリージョンのみ有効化する方法では、この部分の考慮が不要です。

コスト

全リージョン有効化の場合は、前述の「Config.1」の評価でAWS Security Hubセキュリティチェックの課金が行われます。

1リージョンあたりは小さいためアカウント数が少いと影響は小さいです。

逆にアカウント数が多いとそれなりの金額になるため、全リージョン有効化の場合コスト観点で「Config.1」は無効化しておいた方が安心です。(中央設定で、無効化するコントロールを設定できるので手間は大きくないです。)

以下は金額の例です。

例) 30リージョン・50アカウント・チェックは12時間周期(※1)

90 USD = 30(リージョン数) * 50(アカウント数) * 60(チェック回数/月) 　* 0.001(USD チェックごとの料金※2)

※1 定期的なチェックの周期は12時間または24時間以内に行われる。仮で12時間を設定。
※2 料金 - AWS Security Hub | AWS

おまけ: AWS Control Tower利用時のAWS Config有効化リージョン

AWS Control Towerの管理対象リージョンで、AWS Configが有効になります。

AWS Control Tower管理対象外のリージョンでは、AWS Configが有効ではないため「案1 全リージョンをリンクする」を採用する場合、AWS Security Hubセキュリティ標準のコントロール「Config.1」が検知されます。

解消するには、コントロールを無効化するかAWS Configを有効化する必要があります。

AWS Control Towerで管理対象リージョンに追加することで、AWS Configを有効化することが可能です。

しかし、公式ドキュメントには以下の記述があるため、利用しないリージョンの場合は追加することは避けたほうが良さそうです。

ワークロードを実行する必要がない AWS リージョンに AWS Control Tower ランディングゾーンを拡張しないことをお勧めします

AWS リージョンと AWS Control Tower の連携方法 - AWS Control Tower

おわりに

AWS Security Hubの中央設定時の、管理アカウントの扱いについてでした。

個人的には全リージョン有効化がおすすめです。AWS Security Hubで通知を集約できますし、デメリットであるコストの部分も中央設定のおかげで簡単に対応できます。

中央設定は昨年11月リリースで、比較的新しい機能です。今後のアップデートが楽しみですね。

以上、AWS事業本部の佐藤(@chari7311)でした。